1. Field of the Invention
This invention relates to developing a preloaded image of programs and data to be loaded into a computer system before it is delivered to an end user, and, more particularly, to developing such an image in a form that is independent of the hardware configuration of the computer system, and to additionally providing for the installation of device drivers that depend on the hardware configuration.
2. Summary of the Background Art
A typical computing system is delivered to an end user with a “preloaded” image of programs and data, including an operating system, application programs, and various drivers associated with the hardware of the computing system. Generally, large orders of computing systems from a single organization are delivered to the organization without this kind of an image. Then, the image is “preloaded” by an information technology specialist employed by the organization. On the other hand, computers sold in small numbers are generally delivered with the “preloaded” image having been loaded by the manufacturer, or, conceivably, by a value-added retailer.
Generally, the operating system and the application programs receive the most attention from the end user in terms of their perceived value. However, the device drivers are needed to allow operation of various hardware devices within the computing system.
FIG. 1 is a pictographic view of programs and data stored within the hard disk drive 10 of a conventional computing system in the form in which the system is delivered to the end user. This data includes a preloaded image 12, which in turn includes an operating system 14, a number of application programs 16, and a number of device drivers 18. The operating system 14, when loaded, controls the allocation and usage of various hardware resources of the computing system and provides a software foundation for the operation of the application programs 16, and for other application programs which may be subsequently installed. The application programs 16 are each designed to perform a specific task, such as word processing, spreadsheet calculations, accounting, or maintaining address book data. Each of the device drivers 18 permits the computer system to communicate with a particular hardware device within the computer system or with an external device attached to the computer system. Various device drivers 18 may manipulate the associated hardware device to allow the transmission of data to the device, while other device drivers 18 only perform a data translation function. A central hierarchical database 20, associated with the operating system 14 includes data used to locate and use the various device drivers 18. During subsequent operation of the computing system, the device drivers 18 are accessible to the operating system 14 and to the application programs 16. The preloaded image 12 also includes the master boot record (MBR) 22, stored in the first sector within the hard disk drive 10. The MBR 22 stores instructions to locate and begin the process of loading the operating system 14.
For example, if the operating system 14 is Microsoft WINDOWS 9x, WINDOWS CE, WINDOWS NT, WINDOWS 2000, or WINDOWS Me, the database 20 includes a first branch of the Registry, which stores a file known as a key for each entry. The key includes values that specify the type of entry, which may be associated with a device driver, with a service routine, or with a file system. The key also includes a pointer to the location of the device driver or service routine and a value that determines the order in which the device driver or service routine is loaded. The value associated with a device drive indicates that it is to be loaded at boot start by the operating system loader, later by the I/O manager of the operating system after executive subsystems have been loaded, or only on demand. In addition, if the operating system 14 is one of these versions of WINDOWS, the device drivers 18 are stored in a second branch 23 of the registry.
Thus, the device drivers 18 are dependent on the hardware configuration of the computing system. They are, in fact, a reflection of this hardware configuration, including the code necessary to operate these hardware devices. This dependency means that a different preloaded image 18 is needed for each hardware configuration. This requirement places a burden on the organization and individuals preparing and preloading the image 18. For example, it these individuals are responsible for supplying a range of different types of computing systems to end users, a different preloaded image must be developed and loaded for each type of computing system. In addition, when a new type of computer is added to the systems to be delivered, a new image 18 must be developed. Thus, what is needed is a method for using a preloaded image that is independent of the hardware configuration, so that the same preloaded image can by used across a number of different hardware configurations or platforms.
In order to accommodate hardware changes and upgrades, which are expected to occur, the operating system 14 includes means for installing additional device drivers, which are not installed as part of the preloaded image 18. For example, recent versions of Microsoft WINDOWS support a PLUG AND PLAY feature that recognizes installed or connected hardware devices for which a device driver has not been installed, and that then proceeds to find the device driver among a number of uninstalled device drivers stored within data associated with the operating system 14. The device driver may also be installed from a removable medium, such as a compact disk supplied with the operating system or a floppy diskette supplied with a new hardware device.
However, this ability of the operating system 14 to install device drivers cannot be reasonably used as an alternative to installing the necessary device drivers 18 as a part of the preloaded image 18. Even if all of the necessary device drivers were found among the data associated with the operating system 14, the installation of these drivers individually as installed hardware devices are discovered would take far too much time during the initial booting of the operating system 14. Furthermore, there is a likelihood that one or more of the necessary device drivers would not be readily found, and that user intervention would be required to provide removable media storing the device drivers. Thus, what is needed is a method for using a preloaded image that is independent of the hardware configuration while retaining an ability to install device drivers during system initialization.
Thus, the conventional operating system 16 is “transportable,” being used on a number of different kinds of computer systems. For example, various versions of Microsoft WINDOWS are each used on a wide variety of types of computing systems, from large desk-top systems to laptop systems.
One method for making an operating system transportable in this sense is described in U.S. Pat. No. 5,325,532 as a transportable operating system which can be readily configured on a relatively isolated computing system. All non-hardware related functions are contained in a transportable portion of the operating system, while hardware and potential hardware functions are developed through a hardware abstraction layer through appropriate interfaces and calls. The hardware abstraction layer is broken down into a main system read only memory (ROM), which contains a certain minimal number of functions, and various hardware modules, which may be located in ROM or on an adapter board. While a number of U.S. patents describe methods for reducing the level of dependence that device drivers have on the details of a particular hardware configuration, there is no reason to believe that the application of such methods can result in the development of an array of device drivers which is truly independent of the hardware configuration. For example, U.S. Pat. No. 5,291,585 defines a feature table that tracks peculiarities of the actual hardware allowing applications that write directly to the hardware devices to understand what these devices can and cannot do. What is needed is a method allowing installation preloaded image independent of the hardware configuration without placing an additional burden on application programs and without restricting the kinds of application programs which can be run.
While another patent describes ways of modifying an operating system to provide hardware-dependent capabilities, there is no reason to believe that this method can be expected to eliminate a need to install hardware-dependent device drivers. Thus, U.S. Pat. No. 5,640,562 describes a way to incorporate new installation scripts into an existing operating system in order to install and reboot a system using a new platform-specific kernel and new device-specific drivers.
U.S. Pat. No. 5,701,483 describes a device-driver interface for achieving portability of device drivers for operating with a full source level of compatibility across multiple instruction set architectures and platforms. The device driver interface makes transparent to the driver the actual data access mechanisms of the host computers on which the driver is compiled. However, this method leaves the device drivers dependent on the characteristics of the device being driven, so a convenient method of loading hardware-dependent device drivers is still needed.
U.S. Pat. No. 5,291,585 describes a computer system with a self-describing feature table, accessible by device drivers, with a simple process being able to access these feature tables to fully customize the device drivers at installation, or at boot. The device drive may be able to branch on the data in the feature table. However, there is no indication that such a method can eliminate the hardware-dependence of a device drive when it is installed.
U.S. Pat. No. 5,887,169 describes a technique for enhancing a software layer while ensuring backwards compatibility. In one implementation, the software layer is a hardware abstraction layer (HAL) that interfaces between hardware and an operating system. The HAL can be enhanced with additional functionality without having to worry about crashing the operating system if the old hardware is used with the new HAL. Again, there is no indication that the use of this technique eliminates a need to load hardware dependent drivers during system initialization.
U.S. Pat. No. 6,209,089 describes a method for using a temporary connection between a client computer system and a server to update portions of an operating system and device drivers following changes to the client computer system. The server sends information describing the previous hardware configuration of the client system. Then, the client system determines differences between its current configuration and its previous configuration, and sends information describing new devices to the server. The server identifies new drivers and components of the operating system, and stores them in locations from which they are downloaded to the client computer. What is needed is a method for loading device drivers corresponding to the hardware of an actual system without requiring the establishment of a connection with a server or other procedures requiring operator interaction.